Monitoring IBM MQ
Understanding IBM MQ Monitoring with Nodinite
The Nodinite IBM MQ Monitoring Agent provides real-time visibility by continuously evaluating queue depths, message aging, channel connectivity, and listener availability—automatically generating alerts when thresholds are breached.
On this page: Technical details on monitoring each IBM MQ resource type, state evaluation logic, and threshold configuration. For the bigger picture, see the IBM MQ Monitoring Agent.
Why Monitor IBM MQ with Nodinite
Traditional monitoring creates operational challenges: queue depth blindness (backlogs develop unnoticed), no early aging detection, manual channel troubleshooting requiring admin access, limited visibility across environments, and audit gaps. The Nodinite solution provides proactive alerts, trending data, role-based monitoring without exposing MQ admin rights, unified dashboard across unlimited queue managers, and full audit trails for compliance.
Monitoring Architecture
The Nodinite IBM MQ Monitoring Agent operates as a Windows or Linux service that periodically connects to queue managers using the MQ client protocol (MQIC), evaluating six resource categories:
| Category | What Gets Monitored | When Issues Occur |
|---|---|---|
| Queues | Depth (message count), oldest message age, Get/Put inhibition state, quota usage | Messages accumulate faster than consumers can process; old messages indicate stalled processing; inhibited queues block producers |
| Topics | Active subscriptions, pub/sub connectivity | No subscribers listening means messages are silently discarded |
| Listeners | Listener state (running/stopped), port availability, protocol (TCP, LU62, NetBIOS) | Stopped listener blocks all new inbound connections to queue manager |
| Queue Managers | Queue manager connectivity, availability, startup state | Queue manager offline isolates all queues, channels, and connected applications |
| Client Connections | Active MQ client connections, application identifiers, connection status | Connection leaks or abrupt disconnections indicate client application issues |
| Channels | Channel state (running/stopped/retrying), message throughput, last activity timestamp | Stopped channels block inter-queue-manager communication; retrying channels indicate transient connectivity issues |
You can perform various Remote Actions on these resources directly from the Nodinite Web Client or Web API, empowering operations teams to manage issues without RDP or VPN access to MQ servers.
How Resources Are Organized
Each monitored IBM MQ object becomes a Resource in Nodinite. Resources are grouped into Categories by type (queues, channels, listeners, etc.) and assigned to Applications based on the queue manager they belong to.
Resource hierarchy example:
- Application:
Production-QM1(queue manager display name)- Category: Local Queues
- Resource:
ORDERS.IN(local queue) - Resource:
ORDERS.OUT(local queue) - Resource:
ORDERS.DLQ(dead letter queue)
- Resource:
- Category: Channels
- Resource:
PARTNER.EDI(sender channel) - Resource:
LOCAL.RECEIVER(receiver channel)
- Resource:
- Category: Listeners
- Resource:
TCP.1414(TCP listener on port 1414)
- Resource:
- Category: Local Queues
When you create a Monitor View, you filter resources by application, category, and queue manager—giving different teams visibility into the resources they need to monitor. For example, the application team sees only ORDERS.* queues; the operations team sees all resources; the business unit sees only business-critical resource alerts.
Resource Categories showing how IBM MQ objects are organized by type
Example application hierarchy demonstrating queue manager organization in Nodinite
Understanding Queue Monitoring
Queue monitoring tracks three key dimensions for each queue:
Queue Depth – Current message count. High depth indicates processing backlog; Nodinite alerts when depth exceeds warning (typically 70-80% of max) or error (80-95% of max) thresholds.
Message Age – Elapsed time since oldest message arrived. Indicates stalled consumer applications or processing deadlocks. Threshold depends on queue type: critical queues (orders, payments) may alert after 30 minutes; batch queues allow 4+ hours. Note: If a queue has Get inhibited (output disabled), message age cannot be evaluated.
Operational State – Queue inhibition (Get/Put disabled), alias queue validity, access rights, and connectivity to queue manager.
Queue Types Monitored: Local queues, remote queues, alias queues, system queues, and dead letter queues. Each becomes a separate Resource in Nodinite.
Configuration: Set per-queue-manager default thresholds or override for specific queues. See the Configuration page. Once configured, threshold violations trigger alerts to Alarm Plugins (email, Teams, Slack, etc.).
Example list of queues as resources in a Nodinite Monitor View. Each row represents a monitored queue with its current state, depth, and age.
Queue State Evaluation
Each queue (Resource) can have one of the following operational states:
| State | Status | Description | Recommended Action | |
|---|---|---|---|---|
| Unavailable | Resource not available | Evaluation of the queue is not possible due to network or security-related issues. The monitoring agent cannot connect to the queue manager, or the user account lacks permission to query this queue. | Review Prerequisites and verify MQ user account has appropriate access rights. Check network connectivity between agent host and queue manager. See troubleshooting for auth issues. | |
| Error | Not operational | Queue depth exceeds error threshold, oldest message age exceeds error threshold, queue is Get/Put inhibited, or alias queue is misconfigured (not pointing to a valid base queue). | Check application logs. For depth issues, investigate consumer application. For aging issues, verify consumer is running and can access the queue. For inhibited queues, review MQ administrative reasons for inhibition. | |
| OK | Operational | Queue depth is within normal range (below warning threshold), oldest message age is within acceptable range, queue Get/Put state is as expected, and alias targets (if applicable) are valid. The queue is operating normally and processing messages as expected. | No action needed; continue normal operations. Monitor trends over time to establish baselines and identify emerging patterns. |
State Evaluation Examples
Unavailable scenario: Queue manager PROD-QM1 is offline for maintenance. All queues on that manager immediately report "Unavailable" state. The monitoring agent cannot reach the queue manager to evaluate depth or age. Recovery: Wait for queue manager to restart; state automatically returns to OK or Error depending on queue conditions.
Error scenario - High depth: ORDERS.IN queue is configured with 1000 message max depth and error threshold at 900 messages. Consumer application crashes; no messages are processed. Queue depth climbs 100 messages/second. After 9 seconds, queue reaches 900 messages and triggers Error state with alert "Queue depth 900 exceeds error threshold 900." Recovery: Restart consumer application; queue depth decreases as messages are processed.
Error scenario - High age: INVOICES.OUT queue normally has oldest message age <2 minutes. At 13:00, invoice processor encounters database connection error and stops processing. By 14:00, the oldest message on the queue is 60 minutes old (configured age error threshold is 30 minutes). Queue depth is only 50 messages (normal), but message age triggers Error state with alert "Oldest message age 60 minutes exceeds error threshold 30 minutes." Recovery: Investigate database connection; restart invoice processor; queued invoices process within minutes.
OK scenario: ACKNOWLEDGMENTS.IN queue is operating within all thresholds. Depth is 45 messages (warning threshold 700, error threshold 900). Oldest message is 2 minutes old (age threshold 30 minutes). Queue is Get/Put enabled. State is "OK" – no alerts, no action required.
Customizing Queue State Expectations
From within Nodinite Web Client, you can override the state evaluation for individual queues using the Expected State feature. This allows you to:
- Ignore a queue – Set Expected State to "OK" for a queue you're not monitoring (test queue, development queue)
- Expect a different state – Set Expected State to "Stopped" if you intentionally have a queue inhibited for maintenance
- Create business-driven alerts – Set Expected State to "Error" for a queue currently getting unusual volume; suppresses false alerts during known high-traffic periods
Alert History and Trending Data
Understanding historical state changes helps you identify root causes and improve your monitoring thresholds. The Nodinite Monitor View provides historical state search functionality:
What you can analyze:
- State transition timeline – View when a queue changed from OK → Error → OK to understand duration and frequency of issues
- Trend data – See hourly or daily peaks in queue depth or message age to identify patterns (e.g., "Every Friday at 17:00, ORDERS queue depth spikes to 500 messages")
- Correlation analysis – Compare multiple queues' state changes to identify cascading failures (e.g., if consumer app crashes, downstream queue accumulates messages)
How to access history:
- Open a Monitor View that includes IBM MQ resources
- Select the search/history feature (often a "Show history" or "State changes" button)
- Specify a date range and (optionally) select specific queues
- Review the timeline of state changes
See the Add or manage Monitor View page for detailed instructions on using the historical search feature.
Search for alert history for all IBM MQ resources in a Monitor View over a specific time range
Example alert history for a selected queue, showing state transitions over several hours
Topic Monitoring
The Nodinite IBM MQ Monitoring Agent monitors topics by checking if they have active subscriptions. A topic with no subscribers means messages are silently discarded—detecting orphaned topics prevents lost messages in publish/subscribe architectures.
To enable topic monitoring in Configuration: set Topics Monitoring enabled flag = true, configure discovery filters, and set alert thresholds. The agent auto-discovers topics matching your filters.
Topic State Evaluation
Each topic (Resource) can have one of the following states:
| State | Status | Description | Recommended Action | |
|---|---|---|---|---|
| Unavailable | Resource not available | Evaluation of the topic is not possible due to network or security issues. The monitoring agent cannot reach the queue manager or lacks permission to query this topic. | Review Prerequisites; verify MQ user account has PCF (Programmable Command Format) permission for topic queries. | |
| Warning | No subscriptions | Topic exists but has zero active subscriptions. Either subscribers have not yet subscribed (startup phase) or subscribers have disconnected. Messages published now are silently discarded. | Investigate: Is this expected (startup)? Should there be subscribers? Check subscriber applications; restart if needed. Consider if topic should be active. | |
| OK | Has subscriptions | Topic has at least one active subscription registered. Messages published to this topic are being delivered to subscribers. Pub/sub flow is functioning normally. | No action needed; topic is operating as designed. Monitor for subscription count changes indicating subscriber application issues. |
Example: Your application team deployed a new document processing system that publishes events to topic DOCUMENT.EVENTS. Subscribers include email notifier, audit logger, and data warehouse loader. All three subscriptions are active; topic state is OK. Months later, the audit logger application is decommissioned and subscription is removed. Now only 2 of 3 subscribers remain. If no one redeploys the audit logger, you may not notice until compliance audit asks "who is subscribing to DOCUMENT.EVENTS events?" The topic monitoring state remains OK (≥1 subscription exists), but historical data shows subscription count dropped from 3 → 2.
Understanding Listener Monitoring
Listeners are network endpoints accepting inbound connections from clients and other queue managers (TCP, LU62, NetBIOS). A stopped listener prevents all new connections to a queue manager—a critical outage.
Listener State Evaluation
Each listener (Resource) can have one of the following states:
| State | Status | Description | Recommended Action | |
|---|---|---|---|---|
| Unavailable | Resource not available | Evaluation of the listener is not possible due to network or security issues. The monitoring agent cannot query the listener state from the queue manager. | Review Prerequisites; verify network connectivity and MQ user permissions. | |
| Error | Stopped | Listener is explicitly stopped. No new connections to the queue manager can be made. This is a critical condition if the listener should be running. | Immediately investigate the stop reason: Was maintenance performed? Check MQ admin logs. If unexpected, restart listener via MQ commands or Nodinite remote actions (if configured). If intentional (e.g., temporary port reallocation), set Expected State to "OK" and adjust when complete. | |
| OK | Started | Listener is running and accepting new connections. Queue manager is reachable via this listener's port and protocol. | No action needed. Listeners operating normally. |
Example: Your production queue manager PROD-QM1 has TCP listener on port 1414. All client applications connect via this listener. At 14:00, a system administrator accidentally stops the listener during firewall testing. All client applications still connected remain functional (existing connections use established sockets). But new applications trying to connect get "connection refused" errors. The listener state immediately reports Error. Recovery: Restart listener; state returns to OK within 10 seconds; new connections resume.
Queue Manager Monitoring
Queue Manager State Evaluation
Queue managers are top-level IBM MQ services. A queue manager down means the entire infrastructure is unavailable. Each queue manager (Resource) reports "Unavailable" (unreachable) or "OK" (running and accessible).
Example of a queue manager reporting "Not Available" state in Nodinite due to being offline.
Client Connection Monitoring
Client connections are TCP sockets from applications to a queue manager. Monitoring identifies connection leaks (connections not properly closed), runaway clients, and network instability. Each active connection reports details like application ID, channel name, duration, and last activity timestamp.
Understanding Channel Monitoring
Channels are communication links between queue managers (sender/receiver, client/server, cluster) that establish message routing between systems. A stopped or retrying channel blocks all message flow on that link.
Channel Type Reference
| Channel Type | Purpose | Monitoring |
|---|---|---|
| Sender | Sends messages to remote queue manager | Connection state, message flow, last activity |
| Receiver | Receives messages from remote queue manager | Connection state, message backlog |
| Server | Bidirectional client-server channel | Connection count, client details, throughput |
| Cluster Sender | Sends messages within MQ cluster | Connection state, cluster awareness, routing health |
Channel State Evaluation
Each channel (Resource) reports one of three states:
| State | Description | Action | |
|---|---|---|---|
| Unavailable | Agent cannot query channel state due to network/security issues | Review Prerequisites; verify MQ user permissions for channel status (PCF) | |
| Error | Channel STOPPED or RETRYING (connection attempt failed) | For STOPPED: Restart channel if unexpected. For RETRYING: Usually temporary; monitor for stabilization | |
| OK | Channel RUNNING and processing messages (or idle but ready) | No action needed; normal operation |
Example: Sender channel PARTNER.EDI transitions from OK → RETRYING when partner firewall blocks port 1414. Alert notifies operations of expected maintenance window. After firewall re-enabled, channel auto-reconnects and returns to OK state.
Configuring Monitoring Thresholds
All queue depth, message age, and other thresholds are configured via the Configuration page. You can set:
- Global thresholds – Applied to all queues on a queue manager
- Per-queue overrides – Stricter thresholds for business-critical queues, relaxed thresholds for test queues
- Threshold units – Count for depth (messages), duration for age (minutes/hours)
After configuration, monitoring runs continuously based on the polling interval you specify (typically 60-300 seconds). Threshold violations generate alerts propagated to Alarm Plugins configured in Nodinite.
Frequently Asked Questions
For answers to common questions about IBM MQ monitoring, troubleshooting issues, and configuration tips, see the Troubleshooting & FAQ page.
Next Step
Managing IBM MQ – Learn how to purge queues, browse messages, clear dead letter queues, and perform remote management operations
Related Topics
Prerequisites – Verify MQ client libraries, network connectivity, and user permissions
Installation – Deploy the monitoring agent on Windows or Linux
Configuration – Set up queue manager connections, thresholds, and monitoring options
User Access to IBM MQ Monitoring – Delegate read-only or management access to teams
Resources – Understand how IBM MQ objects are represented as resources
Categories – Learn how resources are grouped by type
Alarm Plugins – Configure where alerts are sent (email, Teams, ticketing systems)
Troubleshooting – Resolve common monitoring issues and FAQs